Subject: MIB work items

From: "Peter W. Gayek" <[email-masked]>
Date: Thu, 23 Feb 95 18:09:35 EST

Shannon,
Thanks for the attached comments - I'm sorry to be so slow to respond.
In defining these representations for Xbusy, I was just trying to
fix up the previous object which had some encoding for this capability,
but which didn't really work.  Your point about them being non-standard
is certainly true, and I don't feel strongly that it needs to be the
way I suggested.

So, I have no objection if people want to ditch dlswXBusySupport.  I
do think it's nice to leave a "none" value for dlswPacingSupport just
in case some implementation needs it (although I don't expect this
will ever be the case).  As for dlswTConnFlowCntlMode, it seems to me
that we need at least the values pacing, other, and undetermined.
"Other" would be there for some non-standard (possibly proprietary)
flow control scheme.  This could encompass XBusy if you want.  But
personally I think since XBusy is publicly-defined and will be the
mode for connections to RFC1434+ boxes, it deserves its own value.
Then we are not hiding some information that we actually have.
I have no objection to moving XBusy down in the list of values or
making it very clear this is non-standard.

So my vote is to toss dlswXBusySupport if others share your concern,
but keep dlswPacingSupport and dlswTConnFlowCntlMode support as they
are but with wording and order changes.  Are there other opinions
out there?
Peter
----------------------------- attachment ----------------------------
>From: "Shannon Nix" <[email-masked]>
>Encoding: 4683 Text
>Message-Id: <[email-masked]>
>To: [email-masked]
>Originator: [email-masked]
>Subject: Re: MIB work items
>
>          Hi,
>
>          One couple small comment re: flow control objects.
>
>          1.  I would prefer not seeing non-standard flow-control mechanisms
>              instrumented in the MIB, namely ENTER/EXIT BUSY.
>
>               The implementation agreement reached was: "A DLSw node shall
>               support no-less than "fixed rx, adaptive tx".
>
>               However, recognizing that ...
>
>               a. there are XBusy boxes in the field
>               b. Instrumenting an SNMP agent might be less
>                  effort (certainly independent effort) than bringing the
>                  whole install base to standards level
>
>                ... I could be placated by adding some words characterizing
>                the non-standard enumerated values as non-standard.
>
>                Also I think the order mentioned (pacing vs XBusy) has some
>                implied message as well.
>
>          2.   As agree with your suggestion on removing AdminFlowControl
>               from the transport connection.  I certainly am opposed
>               to coercing a receiver to support fixed pacing.  The decision
>               to vary the window size should be left up to the receiver.
>
>          Best regards, Shannon
>